【レポート】 Amazon EC2 パフォーマンス Deep Dive #AWSSummit

AWS Summit Tokyo 2019

#イベントレポート

#Amazon EC2

#AWS

奥

2019.06.12

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

幕張で開催されているAWS Summit Tokyoの中でもディープなセッションがありました。 Day1 のセッション、「Amazon EC2 パフォーマンス Deep Dive」を受講しましたので、レポートを記載します。

セッション概要

EC2の持つポテンシャルを最大限に利用して効率的な運用をするためのCPU、ネットワーク、ストレージなどといった各種処理性能の理解とチューニングポイントについて

登壇者

小川貴士様宮本大輔様

コンピュート

EC2インスタンスタイプについて

インスタンスタイプ、仮想化方式(kvmかXenか)によってCPU、メモリ、ネットワーク帯域といった性能が異なる。インスタンスタイプはc5d.9xlarge といったように表記される。この場合は、それぞれの記号に対して下記のような意味がある。

c : インスタンスファミリー
5 : インスタンス世代
d : 追加機能
9xlarge: インスタンスサイズ

新型のインスタンスになるほど新型のCPUを使用するため性能が上がり、１時間あたりの稼働コストも下がる。そして最新のインスタンスタイプはニトロシステムという独自のハードウェア、ハイパーバイザの上で最適化されている。そのためハードウェアの性能のほぼ100％を利用者に提供できるようになっている。

正しいAMIとOSの選択

基本的にAMIもOSも最新のものを選択するのが良い。そのことによってパフォーマンスの向上は十分に見込まれる。もちろん利用するソフトウェアなどに応じて対応する必要はある。 Linux系のOSに関しては、カーネルが3.10以上だと良い。しかし、2.6以下に関しては推奨されない。

CPUコアのマルチスレッド処理

EC2上で表示されるvCPUの数はx86_64の物理コア上でのスレッド数を表示している。なので実際の物理コアの数はt2ファミリーのインスタンスを除いて2で割った数になる。そのため、CPUコアのリソースを占有してしまうようなアプリケーションをEC2上に構築する場合は、スレッド数を制御することで性能の向上が見込まれる場合がある。またEC2ではスレッド数を制御する方法をOS上での操作、AWSのAPIを通じての操作でサポートしている。

CPUステート制御

ワークロードによってはC state、P stateの設定を変更する必要が出てくる。

C state: アイドル時のコアのスリープレベルの制御 C0(コアがアクティブで命令を実行している状態)からC6(コアの電源がオフになっている状態)の状態がある
P state: コアに希望するパフォーマンス (CPU周波数) を制御する P0(周波数が最大の状態)からP15(最小限の周波数)の状態がある

詳しくはこちらのドキュメントを参照してください。

Xenベース　インスタンスのチューニング方法

以下の2点を設定することでパフォーマンスの向上が見込まれる

clocksource : をtscにすることで、現在の時刻の取得のためにKernelやハイパーバイザを通らないためオーバーヘッドが減る(Nitroでは不要)
Xen spinlock: t2インスタンス以外のXenベースのものでは無効化すると良い。

NUMA(Non Uniform Memory Access) controls

CPUの数が多くなってきたらNUMAの考慮が必要になる。NUMAはノード(CPUとメモリの対になったもの)をインターコネクトでつないだもの。メモリを共有して処理を高速化するためのもの。しかし、アプリケーションが単一ソケットに収まる以上のメモリを使用する場合や、ソケット間を移動するスレッドがある場合には、NUMAページングを減らすための処理が必要になる。

コンピュート性能のまとめ

インスタンス

ワークロードに適したインスタンスタイプを選択する
最新世代のインスタンスタイプを選択する

OS

最新のOSを選択する

その他

オンプレミスと同じようなチューニングが可能

ストレージ

EBS、インスタンスストア共に適切な選択をすることでパフォーマンスをよりよくできる。

EBS

EC2にネットワーク経由でアタッチするブロックストレージ。内部でのレプリケーションが行われるので高い耐久性と可用性を誇る。様々なインスタンスタイプがあるのでワークロードに合わせて柔軟な選択が可能。

SSD-backed EBS

ランダムI/Oの多いワークロードに適している。汎用的なgp2とio1の二種類ある。

gp2: 1GBあたり3IOPSベースで、最大3000IOOPSまでバースト可能な汎用的なブロックストレージ
io1: 最大64,000IOPSまでサポートする、必要なIOPSをプロビジョンドするブロックストレージ

HDD-backed EBS

サイズの大きいシーケンシャルIOワークロードに適している。高スループットのst1とコールドデータ向けのsc1の二種類ある。

インスタンスストア

EC2が稼働している物理ホストに直接接続されているブロックストレージ。そのため非常に低レイテンシ。しかし、インスタンスタイプによってサイズ、タイプ(HDDかSSD)が固定されており、ものによってはない場合もある。インスタンスの停止、終了、基盤側のディスクで障害が発生した場合にデータが削除されるのであくまで一時領域として使うのが良い。また4096Byte単位でない場合隣接領域への書き込みによりレイテンシが増加する可能性がある。

ブロックストレージの選択基準

最も高いIOPSが必須: インスタンスストアの使用
高いIOPSが必要: io1
高いIOPSを持ちつつコストを重視: gp2
高いスループットが必要: st1

EBS最適化インスタンス

「最適化あり」を選択することで、EBS専用の独立した帯域を使用できる。現行世代のインスタンスについてはデフォルトでオンになっている。帯域についてはインスタンスタイプによって異なるので注意が必要。

またEBSのIOPSが帯域幅より小さい場合は十分に性能を出しきれないので注意が必要(c4.large[4000IOPS]を使用中に、EBS側のIOPSが6000の場合など)。その際は、インスタンスタイプを大きくするか、Nitroインスタンスの場合は一部インスタンスタイプで帯域のバーストができるのでこの機能を使用する。

EBSにおけるRAIDの活用

RAID 0

RAID0でEBS側のIOPSを増やすことは可能だがEC2インスタンス側の性能や、帯域幅は変わらないので注意が必要

RAID 1

内部的にレプリケーションがされているので原則不要。 RAID1を組むと2倍のIOPSとスループットが要求されるので注意が必要。

クラッシュ整合性スナップショット機能

RAIDを構成した場合などの、EBS側での整合性が必要なスナップショットも取れる機能

EBSボリュームの初期化時の注意事項

スナップショットからEBSを復元した場合に初めてアクセスするブロックに対するレイテンシが発生する。なので実際のワークロードに載せる前にddやfioコマンドで先に各ブロックにアクセスをすることでレイテンシが本番環境での動作で発生しないようにできる。

ストレージメトリクスの取得

CloudWatchによるメトリクスの取得が可能。同様にバーストクレジットも確認可能。

ネットワーク

EC2インスタンスの帯域はどんどん拡張されており、現在(12/6/2019)の最大帯域は100GBになっている。最大の表記があるインスタンスに関しては帯域のバースト時の最大帯域となっている。その中でインスタンスタイプや、世代によって帯域は異なるのでネットワーク要件も加味してインスタンスタイプを選択する必要がある。